Field
This disclosure relates generally to error handling in an integrated development environment, and more specifically, to efficiently handling errors generated by tools used to generate processing environment-specific executables, where the tools are external to the integrated development environment.
Related Art
An integrated development environment (IDE) provides a suite of facilities for development of software. Typical IDEs include facilities such as a source code editor, build automation tools, and a debugger. A goal of an IDE is to provide a single user interface for the variety of components used for authoring, modifying, compiling, deploying, and debugging software. Further, the IDE presents the components as a cohesive unit, thereby not only improving productivity, but also improving learning time for developers.
In traditional IDEs, the environment also includes compilers, interpreters, assemblers, and the like, which are used to generate processing environment-specific executable code. These tools are executed in the environment presented by the IDE and provide their output directly to the IDE environment. Thus, any error indications from the various tools are displayed by the interfaces presented by the IDE environment. But, in order to incorporate such tools within the IDE, a binary interface must be provided for each tool to enable interaction. There can be significant programming overhead to generate those interfaces for each new tool desired to be included in the IDE, which limits ease of expansion.
Alternatively, IDEs can use tools that are outside the environment, which then execute as in response to command line entries (e.g., through use of a makefile). This avoids the need to generate a binary interface between the IDE and the external tool, and thereby enhances expandability and utility. These external tools can return output strings in the form of responses to the command line entry. Each output string should then be interpreted and provided back to the IDE in some way, so that a developer can respond to any errors presented by the output strings. Typically, this interpretation is performed by a set of error parsers that examine the output string to determine whether there is a match to an error expression. One problem with such an approach is that for complex builds, many commands for many external tools can be used, and there can be many output strings generated, some of which include error indicators and many of which do not. Nonetheless, each expression is examined by each error parser until it is determined that there is a match or not. Thus, there can be significant overhead associated with examining each output string by each error parser. In some cases, this overhead can be several times longer than the processing time of the build tools themselves.
It is therefore desirable to provide an integrated development environment that can utilize external tools for ease of expansion, but analyze the output of those tools in a manner that is efficient, thereby improving the overall processing time of the IDE and reducing the resources needed during development.
The use of the same reference symbols in different drawings indicates identical items unless otherwise noted. The figures are not necessarily drawn to scale.